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(57) Abstract: A system (Fig. 1) and method for storing features/QoS parameters in a main/central database (MCD, 24 Fig. 1) and 
also in a local context directory (10). A memory transfer agent (12) is used to transfer only active feature contexts from a first router 
^ (6) to a new router (8) during handover. 
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[00011 SYSTEM FOR CONTEXT TRANSFER 

FOR WIRELESS INTERNET DEVICES 

[0002] FIELD OF INVENTION 

[0003] The present invention relates to the field of commnnications. 

More specifically, the present invention relates to supporting microflows by 
the mobile Internet, and to a context transfer approach to supporting 
microflows. 

[0004] BACKGROUND 

[0005] The Internet is increasingly being used to support mobile 

applications. There a growing need to support many different types of 
microflows, including both real-time and non real-time services. 
[0006] In a mobile environment, microflows emanating firom a Mobile 

Node (MN) are characterized by a set of parameters. The parameters define a 
context and the resulting feature contexts may be stored within an access 
router (AR). 

[0007] Some features are specifically defined for a particular microflow, 

while others are defined for all the microflows belonging to the MN. These 
features may be for defining the QoS state, (such as RSVP, DiffServ, COPS), 
maintaining robust header compression, (such as van Jacobson and GRE), and 
security, (such as PKI and AAA). In order to assist in preserving the network 
bandwidth, it is desirable to store these parameters at some node entity 
within the access network, instead of at the MN itself. By doing that, the 
overhead of processing and transmission delay firom the MN to the AR is 
greatly reduced. This saves the transmission bandwidth through the radio 
linlr and makes the design of the MN much simpler. 

[0008] The context transfer protocol is tightly integrated into the 

handover protocols currently developed by the IETF, such as: Fast Handovers 
for Mobile IPv6, Low Latency Handoffs in Mobile IPv4, and Bi-directional 
Edge Tunnel Handover for IPv6. It must support seamless (i.e. 
uninterrupted), loss-less, resumption of services after the handover is 
completed. Therefore, an essential requirement of context transfer is that 
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there must be good synchronization between the handover protocol and the 
context transfer method, and the context transfer must be reliable. 
[0009] The protocol must maintain the integrity of data dxiring the 

context transfer. There must be security association between the two ARs so 
that they can mutually authenticate themselves prior to the transfer of 
context. The context transfer protocol must also minimize the amount of 
processing at the sending and receiving ARs, and it must complete the context 
transfer with a minimum number of signaling messages. 

[0010] It woxild also be desirable for the context transfer protocol to be 

scalable. Scalability means that the context transfer protocol should scale 
with the number of participating MNs, and that it should scale with the 
nimiber of featxire contexts and feature contexts being transferred. 

[0011] SUMMARY 

[0012] The present invention is a system sind method which stores aU 

currently "active" feature contexts locally at the ARs, and stores all "inactive" 
featvire contexts centrally in a main database. The main database can be 
accessed by all the ARs within the same administrative domain. When a new 
microflow becomes active, its active feature contexts are brought from the 
main database and loaded into the local directory, thus replacing any inactive 
feature contexts that are not needed at the time. 



[0013] BRIEF DESCRIPTION OF THE DRAWING(S) 

[0014] * Figiure 1 is a block diagram of the architecture for performing 

context transfer between a pair of ARs. 

[0015] Figure 2 depicts a context transfer L3 trigger message. 

[0016] Figure 3 depicts a context transfer L3 acknowledgement 

message. 

[0017] Figure 4 illustrates a ICMP Message Format for CTR, OTA and 
CTD. 

[0018] Figure 5 depicts the format of feature context object(s) message. 

[0019] Figure 6 illustrates format of a context transfer object. 
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[0020] Figxire 7 depicts a context transfer ESP message format. 

[0021] Figiure 8 is a flow diagram of a method for feature context 

transfer. 

[0022] Tables 1 and 2 provide an overview of the acronyms used in the 

figures relating to the entities and the signals, respectively. 



ENTITIES 



ACRONYM 


MEANING 


LCD 


Local Context Directory 


CTA 


Context Transfer Agent 


MTA 


Memory Transfer Agent 


MN 


Mobile Node 


AR 


Access Router 


MCD 


Main Context Database 


MGL 


Memory Gateway (local) 


MGE 


Memory Gateway (external) 


TABLE 1 


ENTITIES 


ACRONYM 


MEANING 


CTR 


Context Transfer Request 


CTA 


Context Transfer Accept 


CTD 


Context Transfer Denied 


CTINIT 


Context Transfer Initiate 


CTACK 


Context Transfer Acknowledge 


FOR 


Feature Context Request 


FCA 


Feature Context Accept 


FCD 


Feature Context Denied 



TABLE 2 



[0023] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) 
[0024] The preferred embodiment will described with reference to the 

drawing figures wherein like numerals represent like elements throughout. 
[0025] As an overview of the present invention, featm'e contexts are 

maintained within each AR for every MN that is connected to that AR, The 
feature contexts define the microflows of an MN. These feature contexts may 
be "active" or "inactive" depending on whether or not the MN needs to make 
use of it at that time. If at anytime during a session an MN wishes to initiate 
a handover fi:om its current AR Qiereinafter "oldAR") to a different AR 
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(hereinafter "newAR")* it sends a Context Transfer Initiate (CTINIT) message 
to the oldAR. This message may be in the form of a layer 2 (L2) trigger or it 
may be a special layer 3 (L3) packet. Included in the trigger message is the 
identity of the newAR to which the feattire contexts are being transferred. 
After the oldAR has determined the identity of the newAR, it sends a Context 
Transfer Request (CTR) message to the newAR. The newAR may choose to 
accept or reject this request. If the CTR is accepted, the newAR sends back a 
Context Transfer Accepted (CTA) message; otherwise, it sends back a Context 
Transfer Denied (CTD) message to the oldAR. If the feature context transfer 
request is accepted, the active feature contexts for the MN are transferred 
from the oldAR to the newAR. If, on the other hand, the feature context 
transfer request is denied, then the MN attempts to find another newAR as a 
new target for the context transfer. 

[0026] Referring to the block diagram of Figxire 1, the present invention 

will be described in detail. The system 4 for performing a feature context 
transfer between a pair of ARs (from an oldAR 6 to a newAR 8), includes a 
Main Contact Database (MCD) 24, a Memory Gateway (external) (MGE) 26, a 
Memory Gateway (local) (MGL) 22, a plurality of ARs 6, 8 and a plurality of 
MNs 28, (only one of which is shown in Figure 1 for simplicity). 
[0027] It should be noted that although the system 4 shown in Figure 1 

pertains to a single administrative domfidn, (i.e. of all the entities under the 
MCD 24), it would be understood by those of skill in the art, (as also shown in 
FiguLre 1) that there are connections to other ARs within the domain under the 
MGL 22, and also connections outside the domain via the MGE 26. 
[0028] The MCD 24 is a database that contains the feature contexts for 
all MNs 28 being served in the domain. This includes the feature contexts for 
all active and inactive microflows. The MGE 26 is a control entity that 
provides an interface between different Memory Transfer Agents (MTA) 
belonging to different domains. The MGL 22 is a control entity that provides 
an interface between different local MTAs belonging to the same domain. The 
ARs 6, 8 are control xmits that provide an interface to the Internet Protocol 
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(EP) network. The ARs 6, 8 are responsible for assigning an EP address, (or 
any other type of address), to the MNs 28. 

[0029] Each AR 6, 8 includes a Local Context Directory (LCD) 10, a 

Memory Transfer Agent (MTA) 12 and a Context Transfer Agent (CTA) 14. 
The LCD 10 maintains the list of feature contexts for active microflows for all 
MNs 28 associated with that particular AR 6, 8. The CTA 14 is a control 
entity that is responsible for estabhshing the contacts with the new point of 
attachment (i.e. the newAR 8) in order to transfer the active feature context to 
the newAR 8. The MTA 12 is a control entity that is responsible for 
transferring the context of the LCD 10 to the LCD 10 newAR 8. 
[0030] The system 4 of the present invention utilizes selective transfer 

of feature context data. The feature contexts are separated into two 
categories: 1) feature contexts belonging to "active" microflows; and 2) feature 
contexts belonging to "inactive" microflows. As those of skill in the art would 
realize, an active microflow is one which is currently in progress sending 
traffic; whereas an inactive microflow is one which is suspended or stopped 
altogether. All the active featiire contexts have to be available inside the LCD 
10 of the AR (oldAR 6 and new AR 8), while the inactive feature contexts are 
stored in the MCD 24. Whenever a new microflow becomes active, its feature 
contexts are brought from the MCD 24 via the MGL 22 and loaded into the 
LCD 10, thereby overwriting any inactive feature contexts that may be 
present there. In accordance with the present invention, it is not necessary to 
store aU of the featxire contexts locally at the ARs 6, 8, it is only necessary to 
store locally the feature contexts of the active microflows. This helps to 
significantly reduce the size of the LCD 10 since the feature contexts for the 
inactive microflows can be accessed from the MCD 24 when needed. This also 
reduces the time required for the feature context transfer and also reduces the 
bandwidth and processing overhead. 

[0031] The process of handover from the oldAR 6 to the newAR 8 

initiates the feature context transfer process. To start the transfer of feature 
contexts, the MN 28 sends a "trigger" signal to the CTA 14 in the oldAR 6 
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through the wireless interface. This trigger signal may be in the form of a L2 
trigger message, or it may be a separate IP packet. 

[0032] This message is called Context Transfer Initiate (CTINIT). The 

CTINIT comprises an ICMP Echo Request message. The format of the 
CTINIT message is shown in Figure 2. A description of the terminology used 
in Figure 2 follows in Table 3: 



FIELD 


DESCRIPTION 


TYPE 


Echo Request- value 8 


CODE 


CTINIT - code value 1 


1 , n Pit f r\ CI \j ivx 


The 16-bit one's complement of the one's 
complement sum of the ICMP message, 
starting with the ICMP Type. For 
computing the checksum, the checksum field 
is set to 0. 


IDENTIFIER 


unused, provided for future flexibility. 


SEQUENCE NUMBER 


unused, provided for future flexibility. 


NUMADDRS 


The address of the prospective newAR. 


ADDR ENTRY SIZE 


The nimiber of 32-bit words of information 
per each router address, (preferably 2). 


LIFETIME 


The maximum mmiber of seconds that the 
AR addresses may be considered valid. 


MNs IDENTITY 


NAI or L2 address. 


oldAR's IP ADDRESS 


Current AR's IP address. 


NewAR's IP ADDRESS 


[i] Prospective target AR's IP address(es), (i 
= 1..NUMADDRS): 


Preference Level [i] 


The preferability of each newAR[i] as i = 
1..NUM ADDRS the candidate target AR, 
relative to other AR addresses in the same 
domain. A signed, two's-complement value; 
higher values mean more preferable. 



TABLES 

[0033] The CTINIT message provides a Ust of "target" newAR 8 along 



with their associated information. The associated information can change as 
desired by the system operator, but preferably comprises the fields shown in 
Figure 2. For example, the preference level is a value assigned to each AR in 
the domain. The preference level may be based on any criteria set by the 
operator, or may be made the same for all ARs. Preferably, the preference 
level for each AR in the domain is different, and the present inventon, will be 
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described as such. The oldAR 6 selects the newAR 8 with the highest 
preference value. However, if that newAR 8 denies the CTR request, the 
newAR 8 the next highest preference value is targeted. 

[0034] After the MN 28 has transmitted the CTINIT message, it waits to 
receive back a Content Transfer Acknowledgement (CTACK) message. The 
CTACK message comprises an ICMP Echo Reply message. If no CTACK 
message is received within a timeout period, the MN 28 retransmits the 
CTINIT message. This is done repeatedly until either a CTACK is received, or 
a maximum coxint of retries has been reached, whereby the feature context 
transfer to that newAR 8 is abandoned and another newAR 8 is targeted. The 
format of a CTACK message is shown in Figure 3. A description of the 
terminology used in Figure 3 follows in Table 4: 



FIELD 


DESCRIPTION 


TYPE 


Echo Reply - code value 0 


CODE 


CTACK - code value 1 


CHECKSUM 


The 16-bit one's complement of the one's 
complement sum of the ICMP message, 
starting with the ICMP. For computing the 
checksum, the checksiim field is set to 0. 


IDENTIFIER 


unused, provided for future flexibility. 


SEQUENCE NUMBER 


unused, provided for future flexibility. 


MNs IDENTITY 


(NAI or L2 address) 



TABLE 4 



[0035] No CODE value is cxirrently used with the CTACK Echo Reply 

message. For the CTACK message, the MN's identity is echoed back to the 
MN 28, so that it can match it with the MN's identity previously sent with the 
CTINIT message. 

[0036] After the CTINIT message is received, the CTA 14 in the oldAR 6 
sends a Context Transfer Request (CTR) message to the CTA 14 of the newAR 
8. Upon receiving the CTR message, the CTA 14 in the newAR 8 
authenticates the oldAR 6. 

[0037] Authentication ensures that the oldAR 6 is to be trusted and the 

information conveyed is correct. The authentication process is not central to 
the present invention and there are many such processes which are weU 
known in the art that may be used. However one process for authentication is 
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done by establishing a Security Association (SA) between the oldAR 6 and the 
newAR 8. Each SA is given a number, known as a Security Parameters Index 
(SPI), through which it is identified. In order for the oldAR 6 and the newAR 
8 to mutually authenticate themselves, the oldAR 6 must know the SPI value 
of the newAR 8. Likewise, the newAR 8 must know the SPI of the oldAR 6. 
The oldAR 6 sends its SPI value with the payload to the newAR 8, using a 
normal IP routing header. The newAR 8 verifies the SA by noting the SPI, 

■ 

and sends back a CTA if the context transfer request is accepted. When 
sending the CTA message, the newAR 8 also forwards its SPI value to the 
oldAR 6. Thus, in a similar manner, the oldAR 6 verifies the SA by noting the 
SPI value of the newAR6. 

[0038] The newAR 8 sends back a Context Transfer Accepted message 

(CTA) if the CTR is accepted, or a Context Transfer Denied message (CTD) if 
the CTR is denied. If the CTR is accepted, then the feature context transfer 
can proceed normally, otherwise the context transfer is not permitted to 
proceed to that particular newAR 8. 

[0039] The message formats for the CTR, CTA are also ICMP messages. 

CTR is an ICMP Echo Request, while CTA and CTD comprise ICMP Echo 
Reply. The format of the ICMP message for the CTR, CTA and CTD messages 
is shown in Figure 4. A description of the terminology shown in Figure 4 
follows in Table 5: 



FIELD 


DESCRIPTION 


TYPE 


8 - Echo Request, 0 - Echo Reply 


CODE 


2 - CTR. 2- CTA. 3 - CTD 


CHECKSUM 


The 16-bit one's complement of the one's 
complement s\im of the ICMP message, 
starting with the ICMP TYPE. For 
computing the checksum, the checksum field 
is set to 0. 


IDENTIFIER 


used for matching CTRs fi:om sending. 


SEQUENCE NUMBER 


AR with CTAs or CTDs from receiving AR. 


MN's ADDRESS 


Provided in CTR message only. This field is 
absent in CTA and CTD messages. 



TABLE 5 
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[0040] When the CTR is accepted, and the CTA message is sent back to 

the oldAR 6, the transfer of all active feature contexts for the particular MN 
28 from the LCD 10 in the oldAR 6 to the LCD 10 in the newAR 8 is 
performed. This transfer may be accompUshed using any of the data transfer 
and handshaking protocols that one known in the art to transfer data between 
two entities. Several messages are exchanged between the two ARs 6, 8 in 
accordance to insiire coimectivity and authenticity as well as the information 
being transferred. 

[0041] Preferably the active feature contexts of the MN 28 that are 

resident in the LCD 10 of the oldAR 6 are transferred from the oldAR 6 to the 
LCD 10 of newAR 8 in an ESP encapsulated IP datagram. The innermost IP 
datagram contains a common IP header, and following that is a set of feature 
context objects. The basic structure of this datagram is shown in Figure 5. 
[0042] The format of a CT object is shown in Figure 6. The basic 

structure comprises a CT header and a listing of the feature context 
parameters. A description of the terminology used in Figure 6 follows in Table 
6: 



FIELD 


DESCRIPTION 


TYPE 


The type of feature context being 
transferred, (i.e. whether ifs RSVP, iffServ, 
RoHc, AAA keys, etc.) The type value is 
unique to the specific type of featxure context 
being transferred. 


CODE 


Within each TYPE, a number of different 
objects may be defined. For example, RSVP 
defines SENDER.TSPEC, ADSPEC and 
FLOWSPEC objects; DiffServ defines 
DSCP's to emulate PHB's in a Differentiated 
Services network; AAA registration keys. 
Thus, parameters are grouped into different 
sets, as indicated by the CODE values. 
Each particular set of parameters within a 
given class, is transmitted from the sending 
AR to the receiving AR as a separate CT 
object. 


RES 


unused, provided for future flexibihty. 


L 


Last object transmitted. If a CT object with 
the L-bit set is not received within a timeout 
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period, a sxdtable NAK message is sent to 
the sending AR. Also, if a CT object follows 
the CT object with the L-bit set, a similar 
NAK message is sent to the sending AR, 
indicating an error. 


SEQUENCE NUMBER 


Used for maintaining the order of 
transmissions of CT objects, and also for 
reUabihty purposes. If a gap in sequence 
nimiber occurs, a NAK packet is sent to the 
sending AR, indicating the sequence number 
of the object that was not received. 


NUMPARAMS 


Number of feature context parameters 
transferred in this object. 


LIFETIME 


The maximum number of seconds that the 
context transfer object may be considered 
valid. 


CHECKSUM 


The 16-bit one's complement of the one's 
complement sum of the CT object, starting 
with the ICMP Type. For computing the 
checksum, the Checksum field is set to 0. 


MN's IDENTITY 


MN's NAI or L2 identifier. 


PARAMETER(S) 


List of feature context parameters. 



TABLE 6 

[0043] It shoxild be noted that all context transfer messages between the 

oldAR 6 and newAR 8 are encapsulated with IPsec ESP, to hamdle security of 
data. During the establishment of sessions between the ARs, the CTR, CTA or 
CTD messages are represented by ICMP packets and placed in the datagram 
portion of the IP packet. Any feature context to be transferred between the 
ARs 6,8 are likewise encapsulated in standardized objects and placed in the 
datagram portion of the IP packet. A TCP header, ESP header and ESP 
trailer segments are added as shown in Figure 7. The resulting packet is then 
encrypted, to preserve the privacy and integrity of its contents. An ESP 
authentication field is added to end of the encrjrpted packet, and an IPv4 
routing header is added to the beginning of the packet. The routing header 
must be the same as the innermost IP header. 

[0044] The reliabiUty of context transfer signaling messages, (CTINIT, 

CTACK, CTR, CTA and CTD), is provided by the 16-bit checksiun in the ICMP 
header. The checksum is recomputed by the newAR 8, and the resulting value 
is compare with the value in the checksum field of the message. Any 
mismatch is flagged as an error, and a NAK is returned indicating the 
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SEQUENCE NUMBER of the erroneous message in the IDENTIFIER field. 
The original message is then retransmitted by the original sender. 
[0045] Another source of error may be due to mismatch in the actual 

and computed checksum in the CT object header. If this occurs, a NAK is sent 
to the oldAR 6, indicating the SEQUENCE NUMBER of the erroneous GT 
object in the IDENTIFIER field. The NAK may be piggybacked onto another 
message, or sent as a separate message altogether. The resulting CT object is 
retransmitted as part of the same context transfer message, or as a new 
context transfer message. 

[0046] When a new feature context is desired, a signal called Featxire 

Context Request (FCR) is issued by the CTA 14. This message may be in the 
form of an ICMP datagram, including appropriate TYPE, CODE values and 
the identity of the MN 28. On receiving the FCR message, the MTA 14 may 
choose to accept (FCA) or deny (FCD) the request. These two messages may 
also be in the form of an ICMP datagram. The FCR may be accepted if there 
is sufficient space in the LCD 10 to store all the parameters associated with 
the feature context. If the FCR is accepted, the feature context parameters 
are brought from the MCD 24 into the LCD 10 in the newAR 8. 
[0047] Referring to Figure 8, a procedure 100 in accordance with the 

present invention is shown. The procedure 100 transfers active feattire 
context from an oldAR 6 to a newAR 8. The procedure 100 starts with aU 
feature contexts (both active and inactive) being stored at the MCD 24, but 
only active feature context being stored at the oldAR 6 (step 102). Once 
handover is initiated, a retry parameter is initialized (step 104). The retry 
parameter keeps track of the ntunber of retries the MN 28 has made in order 
to send the CTACK message. The MN 28 sends the CTINIT message to the 
oldAR 6 (step 106) and awaits a CTACK message (step 108). The MN 28 
determines whether it has received a CTACK message (step 110). If the MN 
28 has not received a CTACK message then the MN determines whether a 
timeout period has expired (step 112). If the timeout period has not expired, 
thie MN 28 returns to step 108 to await the CTACK message. If the timeout 
period has expired, the retry parameter is increased by 1 (step 114) and the 
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MN 28 determines whether the maximum nximber of retries has been reached 
(step 116). If the maximum number o f retries has not been reached the MN 
28 returns to step 106 and resends the CTINIT message. If the maximum 
number of retries has been reached, the feature context transfer to that 
newAK 8 is abandoned and another newAR 8 may be tsurgeted (step 118). 
[0048] Once the MN 28 determines that it has received a CTACK 

message as determined at step 110, the CTA 14 in the oldAR 6 sends a CTR 
message to the CTA 14 in the newAR 8 (step 120). The CTA 14 in the new AR 
8 authenticates the oldAR 6 (step 122) and the CTA 14 in the newAR 8 sends 
back to the CTA 14 in the oldAR 8 a CTA message if accepted, and sends back 
a CTD message if denied (step 124). 

[0049] If a CTA message has been received by the MN 28 (step 126), 

only the active feature context are transferred from the oldAR 6 to the newAR 
8. If the CTA message has not been received by the MN 28 as determined at 
step 126, step 118 is entered whereby a different newAR 8 is targeted for 
context transfer. 

[0050] Although the present invention is directed to a feature context 

transfer protocol for context transfers between an oldAR 6 and a newAR 8 
within the same domain, it should be tmderstood by those of skill in the art 
that in the event an MN 28 handoffs to a newAR in a different administrative 
domain, the process of transferring feature contexts between the LCDs 10 is 
also the same as hereinbefore described. However, in addition to the transfer 
of the active feature contexts between the LCDs, the inactive feature contexts 
are moved as well, from the ciurrent MCD 24 to a new MCD in the new 
domain. The MCD 24 transfer is accomplished via the MGE 26. 
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CLAIMS 

What is claimed is: 

1. A communication domain having a central node coupled with at 
least a first access router (AR) and a second AR, each of said ARs being iu 
wireless communication with at least one mobile node (MN) via at least one 
active microflow, the commimication domain including a system for 
transferring an MN &om said first AR to said second AR in the event of a 
handover, the system comprising: 

a central database at said central node for storing featm-e 
contexts for all microflows in the communication domain, said feature contexts 
comprising active feature contexts for active microflows and inactive feature 
contexts for inactive microflows; 

a local database at each AR, each local database for storing active 
feature contexts for each active microflow to a NM; and 

a memory transfer agent at each AR, for handling the transfer of 
only said active feature contexts are from said first AR to said second AR in 
the event of a handover. 

2. The system of claim 1, whereby inactive feature contexts may 
also be stored in each said local database. 

3. The system of claim 2 whereby said forwarded active feature 
contexts overwrite inactive feature contexts. 

4. The system of claim 1, further comprising a context transfer 
agent (CTA) at each AR, for determining whether said forwarding of said 
active feature contexts may proceed. 

6. A method for transferring context data from a first access router 
(AR) to a second AR upon handover within a domain containing a plurality of 
ARs, said first and second ARs being coupled to a central node, and said first 
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AR being wirelessly coupled to a mobile node (MN), said wireless coupling 
including an active microflow, tlie method comprising: 

storing all feature contexts related to all microflows within the 
domain at the central node; 

storing active feature contexts related to said active microflow at 
said first AR; and 

initiating handover to said second AR, including forwarding said 
active feature contexts to said second AR. 

6. A commxmication system having a central node coupled with a 
plurality of access routers (ARs), each being in wireless communication with 
at least one mobile node (MN) via at least one active microflow, the 
communication domain including a system for transferring an MN from said 
first AR to said second AR, the system comprising: 

a central database at said central node for storing feature 
contexts for all microflows in the communication domain, said feature contexts 
comprising active feature contexts for active microflows and inactive feature 
contexts for inactive microflows; 

a local database at each AR for storing only active feature 
contexts for each active microflow; and 

a memory transfer agent at each AR, for handling the transfer of 
only said active feature contexts are from a first AR to a second AR. 

7. The system of claim 1, whereby inactive feature contexts may 
also be stored in each said local database, and said forwarded active feature 
contexts overwrite inactive feature contexts. 

8. The system of claim 1, further comprising a context transfer 
agent (CTA) at each AR for forwarding said active feature contexts. 

9. A method for transferring context data from a first access router 
(AR) to a second AR upon handover within a domain containing a plurality of 
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ARs, said first and second ARs being coupled to a central node, and each AR 
being wirelessly coupled to a mobile node (MM) via an active microflow, the 
method comprising: 

storing all feature contexts related to all microflows within the 
domain at the central node; 

storing active feature contexts related to an active microflow at 
said first AR; and 

forwarding only said active feature context £rom sadd first AR to 
said second AR. 
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